Управляемые и неуправляемые типы

Управляемый тип — тип данных, инициализируемый (обычно с помощью оператора new (создать)) в управляемой динамически распределяемой области памяти, но ни в коем случае не в неуправляемой динамически распределяемой области памяти или стеке Попросту говоря, управляемый тип — тип, для которого сборка мусора осуществляется автоматически, потому для освобождения ресурсов, используемых объектами этого типа, нет необходимости использовать оператор delete (удалить). Вместо того чтобы явно удалять объект, можно либо сделать так, чтобы на него не указывал ни один указатель, либо явно приравнять этот указатель нулю. Неуправляемый тип — тип, который игнорируется автоматическим сборщиком мусора, вследствие чего программист должен освобождать занимаемую объектом память с помощью оператора delete (удалить).
Объекты неуправляемых типов никогда не создаются в управляемой динамически распределяемой области памяти, а только либо в неуправляемой динамически распределяемой области памяти, либо в каком-нибудь другом месте памяти, как переменные в стеке или элементы данных другого неуправляемого класса. Поэтому именно неуправляемые типы — это то, с чем привыкли иметь дело программисты C++, тогда как управляемые типы больше похожи на ссылочные типы языка Java, для которых применяется автоматическая сборка мусора.
Ключевое слово _дс (сокращение от "garbage collection" — "сборка мусора") используется для объявления управляемых классов, или структур, и может использоваться для указателей и массивов. Ключевое слово _поде (сокращение от "no garbage collection" — "без сборки мусора") является антонимом _дс (сборщик мусора). Надо иметь в виду, что ключевое слово _дс (сборка мусора) можно использовать только в управляемом коде, а значит, при этом следует использовать параметр компилятора /CLR (Компиляция для выполнения в общеязыковой среде), причем прагма Ipragma unman-aged должна быть неактивна. Ключевое слово _nogc (без сборки мусора) можно использовать как в управляемом, так и в неуправляемом коде. Следующий фрагмент демонстрирует типичное использование _дс (сборщик мусора) при определении управляемого класса:

_gc class ManagedClass
// класс сборщика мусора ManagedClass
{
};

Ключевое слово _поде (без сборки мусора) просто означает, что класс, структура, массив или объект, на который указывает определенный с этим словом указатель, не управляется сборщиком мусора .NET. Данное ключевое слово используется для явного указания, что объект никогда не создается в управляемой динамически распределяемой области памяти. Недопустимо наследование типа, определенного с ключевым словом _дс (сборщик мусора) или _поде (без сборки мусора), от типа, определенного с другим из этих ключевых слов, равно, как не допускается использование _дс (сборщик мусора) в неуправляемом коде.

_nogc class UnmanagedClass
{
};

Заметим, что автоматическая сборка мусора управляемых объектов касается лишь освобождения неиспользуемой управляемой динамически распределяемой области памяти, но не других ресурсов, таких, как дескрипторы файлов или соединения с базами данных.

Управление сборкой мусора

В документации по языкам .NET вы могли встречать описание метода Finalize (Завершить), используемого для освобождения ресурсов, не находящихся в управляемой динамически распределяемой области памяти, но созданных управляемыми объектами. Однако в C++ реализовывать данный метод не надо. Если же все-таки сделать это, компилятор выдаст сообщение об ошибке, указав, что вместо метода Finalize (Завершить) для управляемого класса требуется определить деструктор. Сборщик мусора автоматически вызовет деструктор (в отдельном потоке) при освобождении памяти, занятой объектом; но момент вызова деструктора не определен. А это значит: не следует рассчитывать на то, что деструктор будет вызван при удалении ссылки на объект.
Если вы реализовали деструктор и удаляете управляемый объект явно, деструктор будет вызван сразу, и сборщик мусора уже не будет его вызывать. Можно также, вызвав статический метод GC: :Collect () (Сборщик мусо-ра::Собрать()), вынудить сборщик мусора попытаться освободить память из-под объекта, а вызов деструктора синхронизировать с завершением работы сборщика мусора при помощи статического метода GC: :WaitForPending-Finalizers. Впрочем, обычно неудобно и неэффективно вызывать сборку мусора принудительно или синхронизовать ее с вызовом деструктора, поэтому, если необходимо выполнять очистку в определенный момент, рекомендуется реализовать это независимо в отдельном методе, а затем вызывать его явным образом. Этот метод рекомендуется называть Dispose (Ликвидировать). Рассмотрим следующую программу.

//ManagingGC.срр
fusing <mscorlib.dll>
using namespace System;
// использовать пространство имен Система;
_gc class ManagedClass
// класс сборщика мусора ManagedClass
{
public:
ManagedClass ()
{
Console::WriteLine("c'tor");
}
~ManagedClass ()
{
Console::WriteLine("d'tor");
}
};
void main(void)
{
Console::WriteLine("start"); // начало
ManagedClass *pmc = new ManagedClass;
// Раскомментируйте следующую строку
// для предотвращения вызова деструктора
//GC::SuppressFinalize(pmc); // СБОРЩИК МУСОРА
Console::WriteLine("middle"); // середина
// Раскомментируйте следующую строку
// чтобы вызвать деструктор пораньше
//delete pmc; // удалить
pmc = 0;
// ... или две следующие строки для того,
// чтобы вызвать деструктор пораньше
//GC::Collect(); // СБОРЩИК МУСОРА:: Собрать
//GC:-.WaitForPendingFinalizers () ; // СБОРЩИК МУСОРА
Console::WriteLine("end"); // конец
}

Приведем результат работы программы. Обратите внимание, что деструктор вызывается после того, как программа напечатает end (конец).

start // начало
c'tor
middle // середина
end // конец
d'tor

Однако, если раскомментировать строку, содержащую вызов метода SuppressFi-nalize, деструктор не будет вызван вообще, что доказывается следующей выдачей.

start // начало
с' tor
middle // середина
end // конец

Кроме того, если раскомментировать оператор, в котором используется delete (удалить), деструктор будет вызван до того, как программа напечатает end (конец).

start // начало
c'tor
middle // середина
d'tor
end // конец

Наконец, если раскомментировать только два оператора, содержащих вызовы методов Collect (Собрать) и WaitForPendingFinalizers, деструктор опять будет вызван до того, как программа напечатает end (конец) В этом случае вызов метода Collect (Собрать) приводит к вы зову деструктора, а метод WaitForPendingFinalizers приостанавливает выполнение текущего потока до завершения работы деструктора.

start // начало
c'tor
middle // середина
d'tor
end // конец

Типовая безопасность

Программы, написанные на C++, не обладают свойством типовой безопасности Программы же на управляемом C++ должны гарантированно обладать указанным свойством Однако, из-за того, что программы C++ могут содержать неуправляемый код, они не обязательно обладают свойством типовой безопасности Нельзя производить арифметические операции с управляемыми указателями Кроме того, нельзя приводить тип управляемого указателя к неуправляемому Поэтому можно доказать безопасность только тех программ на C++, которые содержат лишь управляемые код и данные [Управляемый C++ может генерировать код, гарантированно обладающий свойством типовой безопасности, если избегать использования некоторых особенностей языка, таких, как неуправляемые указатели или приведение типов Для проверки типовой безопасности сборки можно использовать утилиту Pevenfy.exe]. Тем не менее, любая программа на C++, в которой выполняются арифметические действия над неуправляемыми указателями или приводятся типы управляемых указателей к неуправляемым, является потенциально опасной.
Следующая программа является примером небезопасного кода на C++, в котором выполняется приведение указателя pumc на неуправляемый объект к указателю на переменную типа j_nt В этом случае подобная операция не является опасной, но в общем случае ее выполнение может представлять опасность Затем выполняется арифметическое действие над указателем на объект, которое уже в этом примере небезопасно, так как получающийся в результате указатель не указывает на какой-либо объект Еще ниже в этом примере, в закомментированных строках, те же действия совершаются над управляемым указателем рте Если бы строки были не закомментированы, компилятор выдал бы сообщение об ошибке

// Unmanaged.срр
# using <mscorllib.dll>
class UnmanagedClass
// класс UnmanagedClass
{
public:
int i;
};
_gc class ManagedClass
// класс сборщика мусора ManagedClass
{
public:
int i;
};
void main(void)
{
UnmanagedClass *pumc = new UnmanagedClass;
pumc->i = 10;
int * pi = (int *}pumc; // Опасно приведение указателя
pi = (int *)(pumc+1); // Опасность: арифметика над указателями
ManagedClass *pmc = new ManagedClass; pmc->i = 10;
//pi = (int *)pmc; // Ошибка: приведение _gc //(сборщик мусора) * к *
//pi = (int *)(pmc+1); // Ошибка, арифметика над _gc // (сборщик мусора) *
}

Типы значений

Ключевое слово _value (значение) похоже на _nogc (без сборки мусора), поскольку оно используется для того, чтобы класс или структура не участвовали в сборке мусора Это полезно для определения объектов в стеке, а не в управляемой динамически распределяемой области памяти Основная цель использования таких типов — возможность создания объектов, не требующих затрат на сборку мусора Использование ключевого слова _value (значение) имеет побочный эффект — класс автоматически становится конечным (ключевое слово _sealed) и не может быть абстрактным (ключевое слово _abstract к нему неприменимо)

_value struct ValueStruct {
int i;
};

Может показаться удивительным, что правила позволяют определять тип _value (значение) там, где не позволяется определять тип _дс (сборщик мусора). В следующем фрагменте кода показан пример этого (вместе с несколькими другими конструкциями). Заметьте, что объекты классов Мап-agedClass, NonManagedClass и ValueClass можно создавать в динамически распределяемой области памяти, тогда как в стек можно поместить объекты только классов NonManagedClass и ValueClass. Последний оператор во фрагменте закомментирован, так как иначе компилятор выдал бы сообщение о недопустимости объявления управляемого объекта как переменной, помещаемой в стек.

//ValueType.срр
#using <mscorlib.dll>
using namespace System;
// использовать пространство имен Система;
_nogc class NonManagedClass
{
};
_value class ValueClass
// класс значения ValueClass
{
};
_gc class ManagedClass
// класс сборщика мусора ManagedClass
{
NonManagedClass nmc; // Странно! Но для компилятора это не ошибка!
ValueClass vc; // Это не ошибка, здесь допускается тип значения
};
void main(void)
{
NonManagedClass *pnmc = new NonManagedClass; //Нет ошибки
ValueClass *pvc = _nogc new ValueClass; //Нет ошибки
ManagedClass *pmc = new ManagedClass; //Нет ошибки
NonManagedClass; //Нет ошибки в стеке
ValueClass vc; //Нет ошибки в стеке
//ManagedClass me; // ошибка, не может быть размещен в стеке
}

Абстрактные типы

Значение ключевого слова _abstract (абстрактный) очень похоже на значение ключевого слова abstract (абстрактный) в языке Java. Оно также напоминает о сложившейся традиции рассматривать класс C++, содержащий хотя бы одну чистую (pure) виртуальную функцию, как абстрактный. Ключевое слово _abstract (абстрактный) делает это объявление явным. Как и в случае ключевого слова _interface (интерфейс), ключевое слово _abstract (абстрактный) используется для обозначения того, что класс определяет некоторые общие обязательные соглашения между кодом, реализующим методы этого абстрактного класса, и кодом клиентов, вызывающих эти методы. Обратите внимание, что, если абстрактный класс определяется как управляемый, в его описании следует использовать также и ключевое слово _gс (сборщик мусора).
Абстрактный класс подобен интерфейсу в том, что он является лишь средством проявления полиморфизма, а создать экземпляр такого класса непосредственно нельзя. Однако, в отличие от интерфейса, абстрактный класс может содержать реализации нескольких, или даже всех своих методов. Абстрактный класс может быть использован как базовый для других классов, экземпляры которых можно инициализировать, причем переменная абстрактного ссылочного типа (т.е. ссылка или указатель, но не тип значения) может использоваться для обращения к экземплярам классов, производных от абстрактного класса.
Обратите внимание на то, что использование ключевого слова _abstract (абстрактный) вместе с _interface (интерфейс) (это слово не является расширением управляемости) является избыточным, так как интерфейсы по определению являются абстрактными. Ключевое слово _abstract (абстрактный) нельзя использовать в комбинации с ключевыми словами _value (значение) или _sealed (конечный). Ключевое слово _value (значение) указывает на то, что объект содержит непосредственно данные, а не ссылки на объекты в динамически распределяемой области памяти. Это значит, что можно создавать экземпляры такого класса, а следовательно, он не может быть абстрактным. Ключевое слово _sealed (конечный) означает, что класс не может быть базовым для других классов, что, очевидно, противоречит концепции абстрактного класса. В следующем фрагменте приведен пример типичного использования ключевого слова _abstract (абстрактный).

//AbstractExample.срр
#using <rnscorlib.dll>
using namespace System;
// использовать пространство имен Система;
_abstract class AbstractClass
// абстрактный класс AbstractClass
{
public:
virtual void Methodlf) = 0; // виртуальный; не реализован здесь
virtual void Method2() // виртуальный; реализован здесь
{
Console::WriteLine("Method2");
}
};
class DerivedClass : public AbstractClass
{
public:
void Method1() // реализован здесь
{
Console::WriteLine("Method1");
}
};
void main(void) » {
//AbstractClass *pac = new AbstractClass; // ошибка
AbstractClass *pac = new DerivedClass; // указатель
pac->Methodl();
pac->Method2();
AbstractClass &ac = *new DerivedClass; // ссылка
ас.Methodl();
ac.Method2() ; }

Профамма напечатает:

Method1
Method2
Method1
Method2

Интерфейсы

Ключевое слово _interface (интерфейс) технически не относится к расширению управляемости, так как его можно использовать и в управляемом, и в неуправляемом коде. Однако оно часто используется при создании управляемого кода, поэтому стоит остановиться для его рассмотрения.
Интерфейсы используются как обобщенные базовые типы для классов, при реализации которых применяются некоторые общие соглашения (контракты). Эти контракты используются для согласования реализации основной программы и программы-клиента посредством определения общего полиморфного набора методов. Интерфейс можно считать крайней формой абстрактного класса, поскольку цели их существования сходны, но интерфейсы — наименее конкретная его разновидность. Так сложилось, что программисты, работающие с C++, используют термин "интерфейс" для обозначения любого класса, содержащего лишь чистые виртуальные методы. Поэтому новое ключевое слово _interface (интерфейс) лишь делает эту договоренность явной.
Класс, определенный с использованием ключевого слова _interface (интерфейс), может содержать лишь общедоступные (public) чистые виртуальные методы. В частности, ни один из методов класса не должен быть реализован, класс не может содержать статические или нестатические элементы данных, конструкторы, деструкторы, статические методы, и не может перегружать операторы. Интерфейс может быть потомком любого количества базовых интерфейсов, но не потомком какого бы то ни было абстрактного или неабстрактного класса. Обратите внимание, что, хотя интерфейс не может содержать элементы данных, он может содержать свойства (доступ к которым осуществляется методами получения/установки (get/set)). О свойствах будет рассказано ниже. Как и в случае абстрактных классов, создать экземпляр интерфейса нельзя, так что они используются как полиморфные базовые классы.
В описании интерфейса можно использовать только спецификатор общего доступа (public); однако его использование не обязательно, поскольку в качестве спецификатора доступа по умолчанию принимается именно public (общедоступный). Исходя из того, что задача интерфейса — определять базовый контракт для производных классов, несложно сделать вывод, что описывать интерфейс с ключевым словом _sealed (конечный) бессмысленно.
К управляемым интерфейсам (т.е. определенным с ключевым словом _дс (сборщик мусора)) предъявляются некоторые дополнительные требования. Они не могут быть производными от неуправляемых интерфейсов. Однако они могут быть непосредственными потомками произвольного количества управляемых интерфейсов. Следующий фрагмент представляет пример типичного использования ключевого слова _interface (интерфейс):

//InterfaceExample.срр
fusing <mscorlib.dll>
using namespace System;
// использовать пространство имен Система;
_interface Somelnterfасе // интерфейс
{
public:
virtual void Methodl() = 0; // чистый виртуальный явный
void Method2(); // чистый виртуальный подразумеваемый
};
class DerivedClass : public Somelnterface
{
public:
void Methodl() // реализован здесь
{
Console::WriteLine("Methodl");
}
void Method2() // реализован здесь
{
Console::WriteLine("Method2");
}
};
void main(void)
{
//Somelnterface *psi = new Somelnterface; // ошибка
Somelnterface *psi = new DerivedClass; // указатель
psi->Methodl();
psi->Method2();
Somelnterface &si = *new DerivedClass; // ссылка
si.Methodl ();
si.Method2 () ;
}

Программа напечатает:

Method1
Method2
Method1
Method2

Упаковка и распаковка примитивных типов данных

Упаковка и распаковка — важная концепция программирования в .NET вне зависимости от того, какой именно язык программирования вы используете. Одно из самых важных преимуществ .NET — унифицированная система типов. Каждый тип, в том числе простые упакованные встроенные типы, такие как _box (int), является потомком класса System.Object (Система.Объект). В языках, подобных Smalltalk, все типы являются объектами, но это приводит к неэффективности использования простых типов. В стандартном C++ простые встроенные типы данных и объекты обрабатываются по-разному, — это повышает эффективность использования типов, но исключает возможность унификации системы типов. Управляемый C++ объединяет преимущества обоих подходов, используя прием, называемый упаковкой (boxing). Упаковка — преобразование типов значений, таких, как int или double (с удвоенной точностью), в ссылку на объект, хранимый в динамически распределяемой области памяти. Упаковка производится с помощью ключевого слова _box. Распаковка — преобразование упакованного типа (хранимого в динамически распределяемой области памяти) в неупакованное значение (хранимое в стеке). Распаковка выполняется приведением типов. Проиллюстрируем упаковку и распаковку следующим фрагментом кода:

int x = 5; // простой встроенный тип int
_box int *po = _box(x); // упаковка
x = *ро; // распаковывание

Ключевое слово _box создает в управляемой динамически распределяемой области памяти управляемый объект, инкапсулирующий копию выражения, имеющего тип значения. Под выражением, имеющим тип значения, подразумевается примитивный тип данных, такой как int, float (с плавающей точкой), double (с удвоенной точностью), или char (символ), либо тип значения, определенный как класс или структура и описанный с использованием ключевого слова _value (значение). Например, предопределенный управляемый тип _boxed_System_Int32 инкапсулирует упакованный int, a управляемый тип _boxed_ValueStruct — упакованный тип значения ValueStruct. Эти странные названия типов (_boxed_System_Int32 и _boxed_ValueStruct) не обязательно будут встречаться в вашем исходном коде, но они показываются утилитой Ildasm.exe. Обратите внимание, что _box int * — альтернативное имя управляемого типа _boxed_System_Int32, a _box ValueStruct* — альтернативное имя управляемого типа _boxed_ValueStruct.
Если ключевое слово _box используется для создания управляемого объекта, сборщик мусора .NET будет автоматически освобождать память, используемую данным объектом. Это похоже на концепцию использования для примитивных типов интерфейсных классов, однако упаковка имеет более важное значение в среде .NET, чем в программировании на обычном C++. Это происходит из-за того, что объекты в C++ можно использовать и как значения, и как ссылочные типы, тогда как в среде .NET управляемые объекты всегда являются ссылочными типами (т.е. ссылками или указателями на объекты, хранимые в управляемой динамически распределяемой области памяти).
Доступ к типам значений осуществляется так же, как и доступ к неупакованным типам. В приведенном ниже коде это делается в присваивании plntBox = 50. Несмотря на то, что plntBox указывает на управляемый объект, разыменованный указатель используется так, как будто он является просто указателем на неупакованный тип int.

//BoxExample.срр
#using <mscorlib.dll>
using namespace System;
// использовать пространство имен Система;
_value struct ValueStruct
{
public:
int i;
};
// функция ожидает получить управляемый указатель на объект
void ExpectManagedObjectPointer(
_box ValueStruct* pManagedObject)
{
pManagedOb]ect->i = 20; // изменяет упакованную копию
Console::WriteLine(pManagedObject->i) ;
}
// функция ожидает получить управляемый указатель на объект
void ExpectBoxedPrimitivePointer(_box int* plntBox)
{
*pIntBox = 50; //изменяет упакованную копию примитивного типа
Console::WriteLine(*рIntBox);
}
void main(void)
{
ValueStruct ValueStruct; // объект типа значение в стеке
ValueStruct.i = 10; // изменяет оригинал распакованной копии
Console::WriteLine(ValueStruct.i);
_box ValueStruct* pManagedObject
= _box(valueStruct); //_boxed_ValueStruct
ExpectManagedObjectPointer(pManagedObject) ;
pManagedObject->i = 30;* // изменяет упакованную копию
Console::WriteLine(pManagedObject->i);
int j; // тип значения - примитивный тип данных
j = 40; // изменяет первоначальный распакованный
// примитивный тип
Console::WriteLine(j);
_box int *p!ntBox = _box(j); // ynaKOBaHHbm_System_Int32
ExpectBoxedPrimitivePointer(plntBox);
}

Приведенная программа напечатает:

10
20
30
40
50

Делегаты

Ключевое слово _delegate (делегат) используется для объявления класса-делегата, основанного на описании сигнатуры метода. Делегаты очень сходны с указателями на функции в обычном C++, с той лишь разницей, что делегат может указывать только на метод управляемого класса. Чаще всего в приложениях .NET Framework делегаты используются для реализации функций обратного вызова или обработки событий. Однако они могут найти применение во всех случаях, когда необходимо вызывать методы динамически.
В .NET Framework определены (как абстрактные классы) два типа делегатов — System: : Delegate (Система::Делегат) и System: :MulticastDelegate. Эти два типа делегатов используются как базовые классы для одноадресных (или делегатов единственного приведения — single-cast) и многоадресных (или групповых — multicast) делегатов соответственно. Одноадресный делегат связывает указатель на метод с методом одного управляемого объекта, тогда как многоадресный делегат связывает указатель на метод с одним или несколькими методами управляемого объекта. Вызов одноадресного делегата приводит к вызову только одного метода, а при вызове многоадресного делегата может выполняться неограниченное количество методов. В связи с тем, что многоадресный делегат можно использовать и для вызова одного метода, одноадресная форма делегата является излишней. Обычно в программах используются лишь многоадресные делегаты.
Встретив в программе ключевое слово _delegate (делегат) компилятор создает особый управляемый класс, производный от System: :MulticastDelegate. Конструктор этого класса имеет два аргумента: указатель на экземпляр управляемого класса (который равен нулю, если делегат связывает статический метод), и сам метод, вызываемый с помощью делегата. Этот класс также содержит метод Invoke (Запустить), сигнатура которого совпадает с сигнатурой метода, вызываемого делегатом. Следующий пример демонстрирует использование делегатов:

//DelegateExample.срр
#using <mscorlib.dll>
using namespace System;
// использовать пространство имен Система;
// определить управляемые классы для использования
// в качестве делегатов
_delegate int SomeDelegate // делегат
(int i, int j);
_delegate // делегат
void SomeOtherDelegate (int i);
_gc class SomeClass
// класс сборщика мусора SomeClass содержит методы,
// вызываемые делегатами
{
public:
int SomeMethod(int i, int j)
{
Console::WriteLine(
"SomeMethod({0}, {!})", _box(i), _box(j));
return i+j; }
static int SomeStaticMethod(int i, int j) // статический
{
Console::WriteLine(
"SomeStaticMethod({0}, {!})", _box(i), _box(j));
return i+j; }
void SomeOtherMethod(int i) {
Console::WriteLine(
11 SomeOtherMethod ({0}) ", _box(i) ) ;
}
};
Void main ()
{
SomeDelegate *pscd; int sum; // сумма
// связать делегат с нестатическим методом
// требуется экземпляр
SomeClass SomeClass * psc = newSomeClass(); pscd = // создать экземпляр класса делегат sc new SomeDelegate(
psc, SSomeClass::SomeMethod); // нестатический sum = pscd->Invoke(3, 4); // вызвать метод через делегат // сумма = pscd->Bbi3BaTb (3, 4); Console::WriteLine(sum); // сумма
// связать делегат со статическим методом, - нет нужды
// ни в каком экземпляре
pscd = // создать другой экземпляр класса делегата sc new SomeDelegate(
О, SSomeClass::SomeStaticMethod); // статический sum = pscd->Invoke(3, 4); // вызвать метод через делегата // сумма = pscd->Bbi3B3Tb (3, 4); Console::WriteLine(sum); // сумма
// объединить два делегата SomeClass * pscl = new SomeClass(); SomeClass * psc2 = new SomeClass(); SomeOtherDelegate *pmcdl = new SomeOtherDelegate(
pscl, &SomeClass::SomeOtherMethod); SomeOtherDelegate *pmcd2 = new SomeOtherDelegate(
psc2, SSomeClass::SomeOtherMethod); SomeOtherDelegate *pmcd =
static_cast<SomeOtherDelegate *>(Delegate:.Combine(
// Объединение делегатов pmcdl, pmcd2)); pmcd->Invoke(1); // Вызвать }
SomeMethod(3, 4)
7
SomeStaticMethod(3, 4)
7
SomeOtherMethod(I)
SomeOtherMethod(1)

происходящем вне него Событие может

используется для указания на то,

Закрепление управляемых объектов

Ключевое слово _pin (закрепить) указывает на то, что указатель на управляемый объект будет оставаться корректным (т.е. общеязыковая среда выполнения CLR не переместит Объект в памяти) на протяжении существования закрепленного указателя. Закрепленный Объект остается на своем месте в памяти до тех пор, пока на него указывает закрепленный указатель. Если изменить указатель так, что он будет указывать на другой объект или присвоить ему нулевое значение, объект может быть перемещен сборщиком мусора. Когда при определении указателя не задано ключевое слово _pin (закрепить), общеязыковая среда Выполнения CLR может в любой момент переместить объект, на который указывает этот указатель. Перемещение объектов происходит вследствие сборки мусора и уплотнения динамически распределяемой области памяти, выполняемых общеязыковой средой выполнения CLR. Эти перемещения не сказываются на управляемом коде, так как общеязыковая среда выполнения CLR автоматически изменяет значения управляемых указателей при перемещении объектов, но могут повлиять на выполнение неуправляемого кода, в котором Используются неуправляемые указатели на управляемые объекты.
Ключевое слово _рш (закрепить) следует применять только в тех случаях, когда это Крайне необходимо, так как закрепление объектов расстраивает сборку мусора и снижает ее эффективность. Для примера необходимости закрепления можно упомянуть ситуацию, в которой вы передаете неуправляемой функции в качестве аргумента указатель На управляемый объект (или указатель на элемент данных такого объекта). В данном случае проблема состоит в том, что в процессе выполнения программы управляемый объект Может быть перемещен сборщиком мусора, но неуправляемая функция будет при этом Использовать старый, некорректный указатель. Это приведет к тому, что неуправляемая функция обратится по некорректному адресу и последствия этого могут быть катастрофическими.
Ниже приведен фрагмент, иллюстрирующий использование ключевого слова _pin (закрепить) в описанной ситуации. Обратите внимание, что объект pPinnedObject закреплен в памяти, так что передача указателя на него методам SetGlobalPointerValue и GetGlobalPointerValue в качестве аргумента является допустимой. Реализация этих методов основана на том, что глобальный указатель дх остается корректным, а это может быть верны только в случае, когда общеязыковая среда выполнения CLR не будет перемещать объект класса ManagedClass. Заметим, что компилятор способен предсказать возникновение такой ситуации и выдаст сообщение об ошибке, если из приведенного примера удалить ключевое слово _pin (закрепить).

//PinExample.срр
#using <mscorlib.dll>
using namespace System;
// использовать пространство имен Система;
_gc class ManagedClass
// класс сборщика мусора ManagedClass
{
public:
int x; };
ttpragma unmanaged // неуправляемый
int *gx; // глобальный указатель void SetGlobalPointer(int* pi)
{
// установить глобальный указатель,
// чтобы указать на управляемый объект
gx = pi;
}
void SetGlobalPointerValue(int i)
{
// установить управляемый объектный элемент данных
// через глобальный указатель
*gx = i;
}
int GetGlobalPointerValue()
{
// получить управляемый объектный элемент данных
// через глобальный указатель
return *gx;
}
Ipragma managed // управляемый
void main()
{
ManagedClass _pin * pPinnedObject = new ManagedClass;
// обратите внимание на ошибку, генерируемую компилятором
//в следующей инструкции...
// если ключевое слово _pin удалить из предыдущей инструкции
SetGlobalPointer(&pPinnedObject->x); // неуправляемый
SetGlobalPointerValue(1); // неуправляемый
int x = GetGlobalPointerValue();//неуправляемый
}

Конечные классы

Ключевое слово _sealed (конечный) указывает на то, что класс или структуру нельзя использовать в качестве базового типа. Другими словами, в иерархии наследования этот класс или структура— терминальный тип. Ключевое слово _sealed (конечный) можно также применять к отдельному методу класса. Конечный метод не может быть переопределен в производных классах. В стандарте C++ подобная возможность не предусмотрена; однако в Java такая возможность реализована с помощью ключевого слова final (конечный). Следующий фрагмент кода является некорректным, так как конечный класс не может быть базовым:

_sealed class SomeSealedClass
{
};
class SomeDerivedClass : public SomeSealedClass // ошибка
{
};

Одной из причин использования ключевого слова _sealed (конечный) является повышение стабильности работы классов за счет препятствования слишком самоуверенным и/или недостаточно квалифицированным программистам испортить важные и сложные элементы поведения классов в производных от них. Другой аргумент использования _sealed (конечный) — предотвращение попыток изменить возможности, обеспечивающие безопасность. Например, предопределенный класс string (Строка) объявлен как конечный, а вдобавок к тому — еще и как неизменяемый (он не содержит общедоступных методов или элементов данных, что могло бы позволить изменять его содержимое). Это делает его идеальным для использования в защитных целях, например, для хранения паролей. При попытке скомпилировать следующий код будет выдана ошибка, так как класс string (Строка) является конечным:

// не допустимо, потому что Система::Строка - конечный класс
class MyString : public String
// класс MyString: общедоступная Строка
{
};

Управляемое приведение типов

Ключевое слово _try_cast приводит к возникновению исключения System: : InvalidCastException при попытке выполнить приведение типов, не поддерживаемое общеязыковой средой выполнения CLR. Это похоже на возникновение исключения bad_cast при выполнении оператора dy-namic_cast в C++ и на исключение ClassCastException, возникающее при некорректном приведении типов в Java. Хотя по своему действию оператор _try_cast больше похож на оператор dynamic_cast, чем на оператор static_cast, _try_cast в действительности задуман как временная замена оператора static_cast, применяемая на стадии разработки приложений. После анализа всех возникающих при выполнении _try_cast исключений и внесения соответствующих исправлений в программу, операторы _try_cast обычно заменяются операторами static_cast. В следующем примере продемонстрировано использование операторов _try_cast для выявления некорректных приведений типов.

//TryCastExample.cpp
fusing <mscorlib.dll>
using namespace System;
// использовать пространство имен Система;
_gc class Mammal
// класс сборщика мусора Млекопитающее
{
};
_gc class Dog : public Mammal
// класс сборщика мусора Собака: общедоступное Млекопитающее
{
};
_gc struct Cat : public Mammal
// сборщик мусора; Кот: общедоступное Млекопитающее
{
};
void main()
{
Mammal *pMammal = new Dog;
// Млекопитающее *pMammal = новая Собака;
try // пробовать
{
Dog *pDog = _try_cast <Dog *>(pMammal); // хорошо
// Собака
*pDog = _ try_cast <Собака *> (pMammal);
Console::WriteLine("_try_cast <Dog *>");
// Собака -
// хорошо
Cat *pCat = _try_cast <Cat *>(pMammal); // плохо!
// Кот *pCat = _ try_cast <Кот *> (pMammal);
Console::WriteLine("_try_cast <Cat *>"); // Кот -
// пропустить
}
catch(InvalidCastException *pe)
{
Console::WriteLine("Ooops: {0}", pe->get_Message());
}
}

Приведенная программа напечатает:

_try_cast <Dog *>
Ooops: Exception of type System.InvalidCastException was
thrown.

Определение ключевых слов в качестве идентификаторов

Ключевое слово _identifier (идентификатор) позволяет использовать любое слово, включая и ключевое, в качестве идентификатора. Его можно использовать и для слов, не являющихся ключевыми, но это не дает никаких преимуществ, и потому является бессмысленным. На первый взгляд кажется нелепым, что такая черта может вообще понадобиться; однако, из-за того, что
платформа .NET допускает использование в разработке приложений одновременно нескольких языков, может оказаться, что имя класса или переменной, определенное в части программы, написанной на другом языке, совпадет с каким-либо ключевым словом C++. Очевидно, что использование в качестве имен ключевых слов значительно усложнит чтение и понимание исходного кода, так что к этому приему следует прибегать только в крайнем случае. Выглядящий несколько странно код, приведенный ниже, демонстрирует этот прием. В нем описывается класс, называющийся if, элемент данных которого называется while (эксцентричное сочетание). Затем создается экземпляр класса if и вызывается метод while. (О, меня уже тошнит!!!) Удивительно, но это компилируется и работает!

//IdentifierExample.срр
#using <mscorlib.dll>
using namespace System;
// использовать пространство имен Система;
_gc class _identifier(if)
// класс сборщика мусора _ идентификатор (если)
{
public:
int _identifier(while) ;
// int _ идентификатор (while);
};
void main(void)
{
_identifier(if)* pif = new _identifier(if);
// _ идентификатор (если)
// * pif = новый _ идентификатор (если);
pif->_identifier(while)= 1;
// pif-> _ идентификатор (while) = 1;
Console::WriteLine(pif->_identifier(while) ) ;
// (pif-> _ идентификатор (while));
}

Обработка исключений

Без сомнения, вы уже хорошо знакомы с механизмом исключений в стандартном C++, так что хорошо понимаете, как работают управляемые исключения. Напомним, что платформа .NET (точнее, общеязыковая среда выполнения CLR) поддерживает расширения, совместимые с расширением управляемости C++, и управляемые исключения, возникшие при выполнении кода, созданного на одном из языков .NET, могут быть перехвачены и обработаны кодом, написанным на любом другом языке .NET.
Кроме обработки предопределенных исключений, таких, как Invalid-CastException или OverflowException, вы можете определить ваши собственные производные от Exception (Исключение) классы, инкапсулирующие некоторую специфичную для приложения информацию. Рассмотрим следующий пример:

//Exceptions.cpp
#using <mscorlib.dll>
using namespace System;
// использовать пространство имен Система;
_gc class MyException : public Exception
// класс сборщика мусора MyException: общедоступное Исключение
{
};
void TemperamentalFunction(int i) // ненавидит нечетные числа
{
Console::WriteLine(
"TemperamentalFunction called with {0}",
i.ToString());
if (i%2 != 0) // если (i%2 != 0), т.е. нечетное
throw new MyException;
Console::WriteLine("No exception thrown"); // Нет исключения
}
void main()
{
try
{
TemperamentalFunction(2); // вызов с четным числом
TemperamentalFunction(3); // вызов с нечетным числом
}
catch (MyException *pe)
{
Console::WriteLine("Exception thrown!"); // Исключение!
Console::WriteLine(pe->get_StackTrace());
}
}

Приведем результат работы программы:

TemperamentalFunction called with 2
No exception thrown
TemperamentalFunction called with 3
Exception thrown!
at TemperamentalFunction(Int32 i) in с:\netcppcode\
chap03\exceptions\exceptions.cpp:line 16
at main() in c:\netcppcode\chap03\exceptions
\exceptions.cpp:line 25

Вот более русифицированная версия этой выдачи .

TemperamentalFunction вызвана с 2
Нет исключения
TemperamentalFunction вызвана с 3
Исключение!
в TemperamentalFunction (Int32 i) в с:\netcppcode\
chap03\exceptions\exceptions.cpp:line 16
в главном () в c:\netcppcode\chap03\exceptions
\exceptions.cpp:line 25

Обратите внимание на метод StackTrace, позволяющий получить текстовую строку, представляющую состояние стека в момент возникновения исключения. Хотя в этом примере ключевое слово _finally (наконец) и не используется, но следует помнить, что такое расширение стандарта ANSI C++ поддерживается в Visual C++. Ключевое слово _finally (наконец) позволяет вставлять в программу код, который выполняется вне зависимости от того, возникло или нет исключение в блоке try. Следует также упомянуть, что ключевое слово _finally (наконец) полностью совместимо с механизмом исключений, поддерживаемым другими языками .NET.
При желании предыдущий пример можно разбить на две части. Первая часть могла быть реализована на С# (в виде динамически подключаемой библиотеки (DLL)) и содержала бы код, при выполнении которого возникало бы исключение. Вторая часть была бы приложением на C++, вызывающим метод TemperamentalFunction. Этим способом можно было бы наглядно продемонстрировать, что исключения действительно являются мостом, соединяющим разные языки .NET.

Атрибуты C++

Visual C++.NET поддерживает использование атрибутов, позволяющих создавать Обычный неуправляемый код, такой, как компоненты модели компонентных объектов Microsoft (COM), даже с меньшими усилиями, чем раньше. Кроме того, Visual C++.NET Поддерживает новые возможности .NET, такие, как Унифицированная модель событий (Unified Event Model). Изначально атрибуты, относящиеся к модели компонентных объектов Microsoft (COM), использовались в отдельном файле IDL (Interface Definition Language — язык описания интерфейсов) для описания информации о типе компонентов Модели компонентных объектов Microsoft (COM). Теперь же эти атрибуты можно использовать непосредственно в исходном коде C++, поэтому необходимость в отдельном файле IDL отпадает. Компилятор использует эти атрибуты для генерации исполняемого Кода и информации о типе. Одно из преимуществ применения атрибутов C++ для программирования с использованием модели компонентных объектов Microsoft (COM) со-СТоит в том, что вам придется возиться только с исходными файлами C++, но не с фай-Дами IDL или RGS (Registry Script — Сценарий системного реестра). Это делает проекты С компонентами на основе модели компонентных объектов Microsoft (COM) более простыми и понятными.
Использование атрибутов значительно изменяет язык C++ и расширяет возможности Модульности программ. Источники атрибутов, в качестве которых могут выступать независимые динамически подключаемые библиотеки (DLL), реализуют механизм динамического расширения возможностей компилятора C++. Атрибуты предназначены для по-Ьышения производительности труда программистов, особенно при разработке компонентов на основе модели компонентных объектов Microsoft (COM). Генерируемый при Использовании атрибутов код автоматически вставляется в конечный файл. Атрибуты используются для создания кода таких элементов:

Хотя данная глава называется "Программирование на управляемом C++", а атрибуты используются при создании управляемого кода, в этом разделе мы рассмотрим лишь использование атрибутов для создания неуправляемого кода на основе модели компонентных объектов Microsoft (COM). Информацию об использовании атрибутов при работе с управляемыми событиями можно найти в разделе этой главы "События". Информацию об использовании атрибутов для других целей можно найти в документации по комплексу инструментальных средств разработки программ .NET ( NET SDK). Атрибуты, определяемые разработчиком, рассмотрены в главе 8 "Классы каркаса .NET Framework".
Продемонстрируем необходимость использования атрибутов в C++ на примере описания функции AddEmUp, приведенного в следующей строке кода. Заметим, что в рамках ANSI C++ эта функция не может быть описана полностью. Так, невозможно указать, какие из аргументов являются входными, а какие — выходными Обычно эта дополнительная информация, важная при создании кода на основе модели компонентных объектов Microsoft (COM), использующего маршалинг, описывается с помощью атрибутов языка описания интерфейсов (IDL) в отдельном файле IDL. При этом атрибуты языка описания интерфейсов (IDL) заключаются в квадратные скобки и могут использоваться для описания многих черт компонентов на основе модели компонентных объектов Microsoft (СОМ), в том числе интерфейсов, соклассов и библиотек типов.

// нет важной информации маршалинга
HRESULT AddEmUp (int i, int j, int.* psum) ;

Приведенную функцию C++ можно описать более подробно в файле IDL, как это показано ниже. Здесь используются атрибуты in (входной), out (выходной) и retval.

.HRESULT AddEmUp(
[in]int i, [in]int 3, [out,retval]int *psum);

Для синтаксического разбора файла IDL, создания библиотек типов и исходных файлов, использующих маршалинг (для заместителя (proxy) и заглушки (stub)), для методов интерфейса модели компонентных объектов Microsoft (COM) (поддерживаются также интерфейсы удаленного вызова процедур (RPC)) используется компилятор языка описания интерфейсов IDL, разработанный фирмой Microsoft, — Midi. exe.
Добавлять атрибуты в исходный код можно вручную Однако полезно будет увидеть, как атрибуты вставляются в проект, генерируемый Мастером приложений библиотеки шаблонных классов (ATL) на основе модели компонентных объектов Microsoft (COM) (ATL COM Application Wizard), который является высокопроизводительным инструментальным средством, предназначенным для создания компонентов на основе модели компонентных объектов Microsoft (COM). На рис. 3.4 показано, как разрешить использование атрибутов в Мастере приложений библиотеки шаблонных классов (ATL) на основе модели компонентных объектов Microsoft (COM) (ATL COM Application Wizard).

Рис. 3.4. Окно ATL Project Wizard (Мастер проектов на основе библиотеки шаблонных классов (ATL)) с установленным флажком Attributed

Следующий фрагмент кода взят из файла MyATLProject, созданного Мастером проектов на основе библиотеки шаблонных классов (ATL) (ATL Project Wizard) при установленном флажке Attributed Обратите внимание, что атрибут module (модуль) применен к проекту в целом, благодаря чему в проекте автоматически генерируются функции DllMain, DllRegisterServer и DllUnregisterServer.

// MyATLProject.срр: Реализация экспорта динамически
// подключаемой библиотеки (DLL).
#include "stdafx.h"
#include "resource.h"
// Атрибут module (модуль) вызывает автоматическую генерацию
// DllMain, DllRegisterServer и DllUnregisterServer
[ module(dll, uuid = "{50434D6D-AAEA-405C-AC49-B9CA769E5D6D}",
// модуль
name = "MyATLProject", // название
helpstring = "MyATLProject 1.0 Type Library",
// Библиотеки Типа
resource_name = "IDR_MYATLPROJECT") ];

На рис 3 5 показано использование Мастера простых объектов на основе библиотеки шаблонных классов (ATL) (ATL Simple Object Wizard) для добавления к проекту простого класса на основе модели компонентных объектов Microsoft (COM), называющегося MyATLClass.

Рис. 3.5. ATL Simple Object Wizard (Мастер простых объектов на основе библиотеки шаблонных классов (ATL))

Мастер простых объектов на основе библиотеки шаблонных классов (ATL) (ATL Simple Object Wizard) добавит приведенный ниже исходный код с атрибутами в файл MyAtlClass .h, а не в файл IDL. Обратите внимание, что атрибуты object (объект), uuid (universally unique identifier— универсальный уникальный идентификатор) и dual (двойной) используются для описания интерфейсов, а атрибуты coclass, progid (программный идентификатор) и version (версия)— для описания классов на основе модели компонентных объектов Microsoft (COM). Эти атрибуты находятся непосредственно в исходном коде C++, поэтому файл IDL не нужен.
// IMyAtlClass
[
object, // объект

uuid("lF9401D8-58BF-469D-845B-A2069CBAFC84") ,
dual, helpstring("IMyAtlClass Interface"), // двойной, Интерфейс
pointer_default(unique) // уникальный
]
_interface IMyAtlClass : IDispatch // интерфейс
{
};
// CMyAtlClass
[
coclass,
threading("apartment") ,
vi_progid("MyATLProject.MyAtlClass"),
progid("MyATLProject.MyAtlClass.1"), // программный идентификатор
version(1.0), // версия
uuid("B3321AD5-3ACE-4820-B134-35FD67120A48"),
helpstring("MyAtIClass Class") // Класс
{
class ATL_NO_VTA5LE CKyAtlClass : // классс
public IMyAtlClass
{
public:
CMyAtlClass()
{
}
DECLARE_PROTECT_FINAL_CONSTRuCT()
HRESULT FinalCor.struct ()
{
return S_OK;
}
void FinalReiease()
{
}
public:
};

В приведенном коде используется атрибут сoсlass, но при этом опущена некоторая информация, присутствующая в коде, сгенерированное прежними версиями АТ!_. Например, отсутствуют карты объектов, карты интерфейсов и сценарии системного реестра. Атрибут coclass обеспечивает все эти, казалось бы, пропущенные возможности. Пропущенный код будет автоматически добавлен компилятором при обработке атрибута coclass.
На рис. 3.6 показан диалог Add Method (Добавление метода), используемый для добавления метода AadEmUp. Обратите внимание на указание атрибутов in (входной), cut (выходной)и retval.
Они обусловливают добавление в файл KyAr iciass . h приведенного ниже кода. Еще раз обратим ваше внимание на то, что атрибуты используются и исходном файле СРР, а не в отдельном файле IDL.
Создание простого проекта на основе библиотеки шаблонных классов ATL (Simple ATL Project)

Создайте проект на основе ATL Server (ATL Server Project):

1. Выберите пункт меню Fiie => New (Файл => Создать). Откроется диалог New Project (Создание проекта).
2. Выберите Visual C++ Projects (Проекты на Visual C++) в окне Project Types (Типы проектов).
3. Выберите ATL Project (Проект на основе библиотеки шаблонных классов ATL) в окне Templates (Шаблоны).
4. Введите MyATLProject в поле Name (Название)
5. Задайте в поле Location (Расположение) папку, в которой будет сохранен проект.
6. Щелкните на кнопке ОК для вызова Мастера проектов на основе библиотеки шаблонных классов (ATL) (ATL Project Wizard).
7. Выберите вкладку Application Settings (Параметры приложения).
8. Убедитесь, что флажок Attributed установлен.
9. Щелкните на кнопке Finish (Готово). Создайте простой объект на основе библиотеки шаблонных классов (ATL):
10. Выберите пункт меню Project => Add Class (Проект => Добавить класс). Откроется диалог Add Class (Добавление класса).
11. Выберите ATL Simple Object (Простой объект на основе библиотеки шаблонных классов (ATL)) в качестве шаблона (Template).
12. Щелкните на кнопке Open (Открыть) для вызова Мастера простых объектов на основе библиотеки шаблонных классов (ATL) (ATL Simple Object Wizard).
13. Введите MyAtlClass в поле Short name (Короткое название).
14. Щелкните на кнопке Finish (Готово) для создания проекта.
Добавьте метод в простой объект на основе библиотеки шаблонных классов (ATL):
15. Щелкните правой кнопкой на интерфейсе IMyAtlClass в окне Class View (Просмотр классов).
16. Выберите пункт меню Add => Add Method (Добавить => Добавить метод). Откроется Мастер добавления методов (Add Method wizard).
17. В качестве названия метода введите AddEmUp в поле Method name (Название метода).
18. Выберите LONG в списке Parameter type (Тип параметра).
19. В качестве имени параметра введите i в поле Parameter name (Имя параметра).
20. Установите флажок in (входной).
21. Щелкните на кнопке Add (Добавить).
22. Выберите LONG в списке Parameter type (Тип параметра).
23. В качестве имени параметра введите j в поле Parameter name (Имя параметра).
24. Установите флажок in (входной).
25. Щелкните на кнопке Add (Добавить).
26. Выберите LONG в списке Parameter type (Тип параметра).
27. В качестве имени параметра введите psum в поле Parameter name (Имя параметра).
28. Установите флажки out (выходной) и retval.
29. Щелкните на кнопке Add (Добавить).
30. Щелкните на кнопке Finish (Готово).

Рис. 3.6. Диалог Мастера добавления методов (Add Method wizard) позволяет указать атрибуты параметра

// IMyAtlClass
[
object, // объект
uuid("lF9401D8-58BF-469D-845B-A2069CBAFC84") ,
dual, helpstring("IMyAtlClass Interface"), // двойной,
// интерфейс
pointer_default(unique) // уникальный
]
_interface IMyAtlClass : IDispatch // интерфейс
[id(l), helpstring("method AddEmUp")] HRESULT AddEmUp([in]
LONG i, [in] LONG j, [out,retval] LONG* psum);
};

Единственное, что осталось сделать в рассматриваемом примере, — вручную реализовать метод AddEmUp в файле MyAtlClass . cpp и скомпилировать приложение. Реализация этого метода приведена ниже

STDMETHODIMP CMyAtlClass::AddEmUp(LONG i, LONG ], LONG* psum)
{
// TODO: Add your implementation code here
// TODO: Добавьте ваш код реализации здесь
*psum = i+j; // добавлен вручную
return S_OK;
}

Создав приложение, его можно протестировать с помощью программы-клиента на основе моде in компонентных объектов Microsoft (COM) Мы не будем рассматривать здесь как это можно Lделать поскольку создание такой программы предполагает применение обычного стиля программирования на устаревшем Visual Basic или Visual C++ Для полччения более подробной информации оекомендлем обратиться к документации по Visual Studio или к любой из множества отличных книг в этой области (например, Understanding and Programming СОМ+, написанной Робертом Дж Обергом (Robert J. Oberg))

В этой паве рассмотрено использование

---